JavaServer Pages (“JSPs”) are an extension to the Java servlet technology from Sun Microsystems that allows HyperText Markup Language (“HTML”) code to be combined with Java code on the same page. The Java code provides the processing and the HTML provides the page layout that will be rendered in the Web browser. JSPs are the primary method in the Java 2 Enterprise Edition (“J2EE”) platform for displaying dynamic Web pages. Special tags allow Java code to be included on the page as well as inserted into HTML statements without invalidating the HTML syntax. Thus, JSPs let non-Java programmers maintain HTML pages in their favorite authoring programs without interfering with the Java code on the page. With the use of standard and custom JSP tags, the Java code can be completely hidden.
At runtime, the application server turns the JSP into a Java servlet (e.g., .jsp file to .java file) using a JSP translator, which is a part of the servlet container. The servlet is then compiled into bytecode (.class) and run on the server like any other servlet. Just as a web server needs a servlet container to provide an interface to servlets, the server needs a JSP container to process JSP pages. The JSP container is responsible for intercepting requests for JSP pages and processes these requests in order to provide the JSP pages to the requester.
To process JSP elements, e.g., directive elements, action elements, and scripting elements, in the JSP page, the container first turns the JSP page into a servlet (known as the JSP page implementation class). The conversion involves converting all template text to printIn( ) statements and all JSP elements are converted to Java code that implements the corresponding dynamic behavior. The container then compiles the servlet class.
The steps of converting the JSP page to a servlet and compiling the servlet make up the translation phase. The JSP container initiates the translation phase for a page automatically when it receives the first request for the page. The JSP container is also responsible for invoking the JSP page implementation class (the generated servlet) to process each request and generate the response. This is called the request processing phase.
As an example of the phases of execution with regard to processing a request for a JSP from a client computing device, a client computing device may send a request for a JSP to a server that includes a JSP container. The server reads the JSP file from a file based I/O system and generates servlet Java code from the JSP file. The reading in of the JSP file and the generation of the servlet Java code from the JSP file constitute a translation phase of the processing of the JSP. Thereafter, the generated servlet Java code is compiled into a servlet class in a request processing phase. The server with the JSP container may then execute the servlet class to return the requested JSP content to the client computing device. As long as the JSP page remains unchanged, any subsequent request goes straight to the request processing phase, i.e., the JSP container on server simply executes the servlet class file. When the JSP page is modified, it goes through the translation phase again including the request processing phase.
The JSP container is often implemented as a servlet configured to handle all requests for JSP pages. In fact, these two containers, a servlet container and a JSP container, are often combined in one package under the name “web container.” Typical JSP containers provide a rigid implementation for the management of JavaServer Page resources. Input resources, such as JSP pages, JSP documents, tagfiles and tag library descriptors (“TLDs”) are expected to be read from file based input/output (“I/O”) systems. Generated resources, such as the generated source code for the JSP servlet are also expected to be read from/written to file based I/O systems. However, the repeated compilation of Java code causes inefficiencies in the lifecycle of the JSP page, especially where custom pages need to be recompiled many times.